home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16619 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB
  1. Path: news.polymtl.ca!news
  2. From: Pierre Ferland <pierre@meca.polymtl.ca>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: C++ experts only
  5. Date: Thu, 11 Apr 1996 10:37:32 -0400
  6. Organization: Center for Applied Research on Polymers
  7. Message-ID: <316D192C.2781@meca.polymtl.ca>
  8. References: <4jhrb4$gk2@melon.myna.com> <3164559A.41C6@meca.polymtl.ca> <4k9blh$8a@news2.ios.com>
  9. NNTP-Posting-Host: pegase.meca.polymtl.ca
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.01 (X11; I; IRIX 5.3 IP20)
  14.  
  15. Vlastimil Adamovsky wrote:
  16.  
  17. > Not having a standard garbage collection is an advantage. If you ever
  18. > need one, buy it. Generally you don't need it. If you think you need
  19. > it and you think you cannot buy your favorite garbage collector
  20. > anywhere, then use Smalltalk. It has a garbage collector.
  21. > Simply, don't create garbage in your programs and you will not to need
  22. > to collect it.
  23.  
  24. Buying a garbage collector would be another way of patching C++ lacks,
  25. as when we have to purchase/test/reject API packages and other
  26. stuff.  We spend too much time looking for tools to help us
  27. in the development process.  Each tool has its bugs, non portability
  28. problems, costs, documentation and philosophy.  The key problem
  29. is that we now have to develop high level applications (that include
  30. graphics, multi-threads, sounds, networks, GUI) while we use a
  31. low-level language like C++.
  32.  
  33. When I talk about garbage collection, the point is not really the
  34. objects destruction: people should delete their objects when no longer
  35. needed, I agree.  But the C++ concept of a pointer really isn't
  36. sufficient.  How many references are made to a specific object ?
  37. Which client is allowed to do what on that object ? Is this
  38. a valid pointer ?  All we can do is wrap our pointers into
  39. more intelligent classes, and... deal with the libraries.
  40.  
  41.  
  42. > We can call it an evolution, which is to preffer to revolution.
  43.  
  44. Depends on how long it takes to change, and on how many libraries
  45. will need to be changed, since, remember your point, C++ can
  46. do virtually anything as long as you build the appropriate library.
  47. If the long term efficiency of C++ is based upon a good
  48. set of libraries and tools, you'd better not have to touch
  49. the basic ones!
  50.  
  51.  
  52. > >The issue should not be C versus C++, forget about C.
  53. > >But don't trust C++ neither.
  54.  
  55. > In god we trust.
  56.  
  57. Yup!  I also used to trust spring, but I recently lost my
  58. innocence on that point!
  59.  
  60.  
  61. Pierre Ferland
  62.